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(54) Title: METHOD FOR IMPLEMENTING A TRANSPORT LAYER PROTOCOL FOR WIRELESS PACKET DATA DELIVERY 



(57) Abstract 

The present invention is a transport layer protocol for data packet 
delivery in a wireless environment. The method of the present invention 
incorporates a transport data protocol structure to implement a modified 
go-back-n automatic repeat request for data packet delivery. The 
invention further employs a distinct pair of sequence numbers and 
request numbers for client and server originated data packet transmissions. 
Several packets can be transmitted by the sender without the need for 
each packet to be individually acknowledged by the receiver. After n 
successive packets have been transmitted, the sender polls the receiver 
for an acknowledgment. The acknowledgment (350) sent by the receiving 
party contains the request number equal to the sequence number of the 
packet that the receiver requests to be sent next (325). This number 
represents the last packet which was received in order plus one (325), 
Lastly, the present invention provides a method for the client and server 
to imply that an acknowledgment (350) has been sent to it even though 
the acknowledgement was lost in transmission. 
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METHOD FOR IMPLEMENTING A TRANSPORT LAYER 
PROTOCOL FOR WIRELESS PACKET DATA DELIVERY 

BACKGROUND OF THE INVENTION 
5 Technical Field of the Invention 

The present invention pertains in general to a 
transport layer protocol and more particularly, to a 
method for implementing a modified go-back-n automatic 
repeat request protocol in the transport layer for 
10 wireless packet data delivery. 

Description of Related Art 

The International Standards Organization (ISO) has 
established a seven layer model regarding communication 
protocols. The forth layer of this model is referred to 

15 as the transport layer and is responsible for packet data 
delivery between a client and a server. To date, the vast 
majority of communication using packet data delivery has 
occurred via a wireline link. A standard solution for 
providing reliable packet data delivery in the wired 

20 environment is the use of Transport Control Protocol 
(TCP) . Transport Control Protocol was designed for wired 
environments characterized by relatively reliable physical 
connections between communication devices having large 
memories and computing power. 

25 For various known reasons Transport Control Protocol 

is unsuited for the harsh environment of wireless packet 
switched networks. For example, Transport Control 
Protocol requires a large memory to store both the 
software for implementing the Transport Control Protocol 

30 and the numerous data packets necessary for implementing 
the Transport Control Protocol's automatic repeat request 
methodology which allows for the receipt of out-of-order 
packets. Wireless communication, however, is 

characterized by the use of radios with small memories and 

35 limited computing power as compared to the wired 
environment . A further problem related to the use of 
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Transport Control Protocol in the wireless environment is 
the large number of acknowledgments required between a 
client and a server during a communication session. In 
a wireless environment there is a greater chance for 
5 unsuccessful transmissions due to interference and 
collisions. The numerous acknowledgments required by the 
Transport Control Protocol leads to increased 
retransmissions, is inefficient in the wireless 
environment, and occupies valuable communications 

10 resources. 

It would be advantageous, therefore, to devise a 
method for implementing a transport layer protocol in a 
wireless environment requiring less memory space for 
receiving data packets and reduced numbers of 

15 acknowledgments. 

SUMMARY OF THE INVENTION 

The present invention employs a multi-field 
transport data protocol structure for conducting a 

20 communication session. A modified go-back-n automatic 
repeat request is used to provide reliable data packet 
delivery requiring minimal memory space and computational 
power. The present invention numbers non- acknowledgment 
data packets sequentially using sequence numbers. Several 

25 packets are then transmitted by the sender without the 
need for each packet to be individually acknowledged by 
the receiver. After a given number of packets have been 
transmitted, the sender polls the receiver for an 
acknowledgment. A response to the requested 

30 acknowledgment includes a request number indicating the 
sequence number of the packet the receiver wants to be 
sent next. If all the packets sent are successfully 
received, the request number will equal the sequence 
number of the next packet to be sent. Otherwise, the 

35 sender begins retransmission starting with the packet 

having the request number. 
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The present invention provides for a separate and 
distinct pair of sequence numbers and request numbers for 
client originated data transmissions and server originated 
data transmissions. Thus, for client originated data 
5 transmissions, the client sequentially numbers transmitted 

data packets with one set of sequence numbers and the 
server responds with request numbers equal to the sequence 
number of the data packet next expected to be sent. 
Conversely, for server originated data transmissions, the 

10 server sequentially numbers transmitted data packets with 

another set of sequence numbers distinct from client 
originated transmissions and the server responds with 
request numbers equal to the sequence number of the data 
packet next expected to be sent. 

15 The present invention further provides a method for 

the client and server to imply that an acknowledgment has 
been sent even though the acknowledgment may have been 
lost in transmission. The client and server imply an 
acknowledgment if a subsequent packet is received having 

20 an expected sequence number. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the method of the 
present invention may be acquired by reference to the 
25 following Detailed Description when taken in conjunction 
with the accompanying Drawings wherein: 

Figure 1 is a Transport Protocol Data Unit for 
implementing the present invention; 

Figure 2 is a sequence diagram for initiating a 
30 communication session; 

Figure 3 is a flow diagram for implementing the go- 
back-n automatic repeat request method of the present 
invention; 

Figure 4 is a sequence diagram for transmitting data 
35 from a client to a server without the loss of any data; 

Figure 5 is a sequence diagram for transmitting data 
from a client to a server when a packet of data is lost; 
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Figure 6 is a sequence diagram for requesting and 
transmitting data from a server to a client; and 

Figure 7 is a sequence diagram for requesting and 
transmitting data from a server to a client when 
5 acknowledgment messages are unsuccessfully transmitted. 

DETAILED DESCRIPTION OF THE INVENTION 

Referring now to Figure 1, there is illustrated a 
Transport Protocol Data Unit (TPDU) 100 for implementing 

10 the transport protocol of the present invention. The TPDU 
100 contains a header 110 and a trailer 120. Included in 
the TPDU 100 is a data portion 130 which, together with 
the header 110 and trailer 120, is limited to a maximum 
of four hundred sixty- four bytes for the entire TPDU 100. 

15 The least significant seven bits of the second byte of the 
TPDU 100 comprises a command/response field 140. The most 
significant bit of the second byte of the TPDU 100 
comprises a response bit (R)150. If the response bit 150 
is clear (i.e. 0), then the TPDU 100 is a command TPDU and 

20 the command/ response field 140 contains either a command 
or an indication that the TPDU 100 contains data in the 
data portion 130. The third byte of the TPDU 100 
comprises a response field 160. 

A command TPDU does not contain a response, and 

25 therefore, the response field 160 is set to a zero value. 

On the other hand, if the response bit 150 is set (i.e. 
1) , then the TPDU 100 is a response TPDU and the 
command/response field 14 0 contains the command to which 
the TPDU 10 0 is responding. The response field 160 

30 contains the response to the command indicated in the 
command/response field 140. 

The third bit of the fourth byte of the TPDU 100 
comprises a poll bit (P)170. The poll bit 170 is used to 
request an acknowledgment. When the poll bit 170 is clear 

35 (i.e., 0), the receiver continues to receive data without 

sending an acknowledgment. When the receiver receives a 
TPDU 100 having the poll bit 170 set (i.e., 1), the 
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receiver sends an acknowledgment to the sender. The 
fifth byte of the TPDU 100 comprises either the most 
significant eight bits of a session ID 181 or an eight bit 
value representing a retry time 182. During an 
5 initialization command sent by a client to a server the 

session ID has not yet been defined and the fifth byte of 
the TPDU 100 contains an eight bit value informing the 
server of the initial retry timeout value. This value has 
a five second resolution making the initial retry time in 

10 seconds equal to five times the value provided in this 
field. Upon receiving the initialization command, the 
server sends an acknowledgment to the client containing 
the most significant eight bits of the session ID 181 in 
the fifth byte and the least significant eight bits of the 

15 session ID 183 contained in the sixth byte of the TPDU 

100. The most significant eight bits of the session ID 
181 together with the least significant eight bits of the 
session ID 183 comprise a sixteen bit value identifying 
the current communication session between the client and 

20 the server. All TPDUs transmitted between the client and 
the server must contain the session identifier, otherwise, 
the data will be ignored. 

The seventh and eighth byte of the TPDU 10 0 comprises 
the sequence number 180 and the ninth and tenth byte of 

25 the TPDU 100 comprises the request number 190. Every TPDU 

contains a unique sequence number identifying that 
particular TPDU 100. When a communication session between 
a client and a server is set up, numbers based on the 
current time of day are selected for client originated 

30 sequence number 180 and for the server originated sequence 
number which is communicated to the server via the request 
number 190. For the duration of the communication 
session, each TPDU 100 is identified with sequentially 
increasing sequence numbers 180. 

35 The last two bytes of the TPDU 100 forming the 

trailer 120 contain a sixteen bit cyclic redundancy check 
for the TPDU 100. 
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Ref erring additionally now to Figure 2, there is 
illustrated a sequence diagram for initiating a 
communication session. To initiate a communication 
session between a client 200 and a server 210, the client 
5 200 transmits an initialization TPDU 220. The 
initialization TPDU 220 includes an initialization command 
contained within the command/response field 140, a time 
based sequence number y contained in the sequence number 
field 180 and an initial retry time out represented by a 
10 number in the retry time field 182 which is equal to the 
number of seconds divided by five. Upon receiving the 
initialization TPDU 220 the server 210 transmits an 
acknowledgment TPDU 23 0 to the client 200 containing an 
acknowledgment response in the response field 160, the 
15 most significant byte 181 and least significant byte 183 
of the session ID, the initialization command in the 
command/response field 14 0 and a request number y+1 in the 
request number field 190. The request number y+1 
transmitted by the server 210 signifies that the server 
20 210 is expecting to receive the next sequentially numbered 
TPDU following the initialization TPDU 220 (i.e., the y+1 
numbered TPDU) . Upon receipt of the acknowledgment TPDU 
230 the client 200 proceeds to transmit a data TPDU 240 
containing data in the data field 13 0 and an indication 
25 of the presence of data in the command/response field 140. 

The data TPDU 240 contains a sequence number of y+1 
contained in the sequence number field 180. 

Referring additionally now to Figure 3, there is 
illustrated a flow diagram of the present invention for 
30 implementing the go-back-n automatic repeat request 
methodology. After a communication session has been 
initiated, the party currently receiving data packets 
listens for a received TPDU (step 300) . When a TPDU is 
received the receiving party compares the sequence number 
35 180 of the received TPDU against the expected sequence 

number (step 310) . The expected sequence number is the 
next number in sequence following the sequence number of 
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a previously, correctly received TPDU. If the sequence 
number 180 of the TPDU does not match the expected 
sequence number, the receiving party discards the received 
packet (step 320) . If, on the other hand, the sequence 
5 number 180 of the TPDU matches the expected sequence 
number the receiving party increments the expected 
sequence number (step 325) and performs an operation on 
the TPDU (step 33 0) in accordance with the command 
contained in the TPDU field 14 0. After the receiving 
10 party has operated on the data (step 330) , or discarded 
a packet containing a sequence number 18 0 other than the 
expected sequence number (step 320) the receiving party 
determines whether the pole bit 170 is set on the received 
TPDU (step 340) . If the pole bit 170 is not set the 
15 receiving party returns to continue monitoring for further 
transmitted packets (step 3 00) . If, on the other hand, 
the pole bit 170 is set, the receiving party sends an 
acknowledgment (step 350) to the sending party, and then 
returns to continue monitoring for transmitted packets 
20 (step 3 00) . The acknowledgment sent by the receiving 

party contains the request number 19 0 equal to the 
sequence number 180 of the packet that the receiver 
requests to be sent next. This number represents the last 
packet which was received in order plus one. The method 
25 described in the flow diagram of Figure 3 applies equally 
both to client and server originated transmissions. 

Referring additionally now to Figure 4, there is 
illustrated a sequence diagram for transmitting data from 
a client 200 to a server 210 when no data packets have 
30 been lost. After a communication session has been 
established, the client 200 proceeds to transmit data 
packets to the server 210. The number of packets p which 
the client 200 transmits to the server 210 before 
requesting an acknowledgment is set by the user. The 
35 client 200 transmits multiple data packets to the server 
210 and eventually the client 200 transmits the p-1 data 
packet 4 00 having a sequence number 180 of a. Since one 
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additional data packet is to be transmitted prior to 
requesting an acknowledgment, the pole bit 170 of the TPDU 
400 is not set. The client 200 then transmits the pth 
data packet 410 with the pole bit 170 set. Upon receiving 
5 the TPDU 410 the server 210 determines that the pole bit 

17 0 is set and transmits an acknowledgment TPDU 42 0 
containing a request number 190 of a+2 . In this 
illustration no data packets have been lost and the 
requested number a+2 of the acknowledgment TPDU 420 is 

10 equal to the sequence number 180 for the TPDU that should 

next be transmitted by the client 200. 

Referring additionally now to Figure 5, there is 
illustrated a sequence diagram for transmitting data from 
a client to a server where a packet of data has been lost. 

15 As with Figure 4, the client 200 of Figure 5 has initiated 
a communication session and is in the process of 
transmitting data packets to the server 210. The client 
200 transmits TPDU 500 containing a sequence number 180 
of b. The TPDU 50 0 is successfully received by the server 

20 210 which increments its expected sequence number by 1 
thereby expecting the next TPDU to contain a sequence 
number 180 of b+1. The client 200 transmits data TPDU 510 
with a sequence number 180 of b+1 which, for whatever 
reason, is not received by the server 210. The client 200 

25 having no knowledge of the unsuccessful transmission 
continues with the transmission of TPDU 52 0 containing a 
sequence number 18 0 of b+2 which is received by the server 
210. Since the sequence number b+2 of TPDU 520 does not 
match the expected sequence number b+1, the server 210 

30 discards the packet. The server 210, however, recognizes 
that the pole bit 170 of TPDU 520 is set and in response 
generates an acknowledgment TPDU 53 0 containing a request 
number 190 of b+1 (instead of b+3) . Upon receiving the 
acknowledgment TPDU 53 0, the client 200 begins 

35 retransmission of data packets starting with TPDU 510 
having a sequence number 180 of b+1. 
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Referring additionally now to Figure 6, there is 
illustrated a sequence diagram for transmitting data from 
a server 210 to a client 200. This diagram includes 
server 210 originated data transmissions and illustrates 
5 the distinction between sequence numbers 18 0 and request 
numbers 190 associated with client 200 originated and 
server 210 originated transmissions. 

The client 200 initiates a communication session by 
transmitting an initialization TPDU 600. The 

10 initialization TPDU 600 contains a randomly generated 
sequence number 180 of y for client 200 originated 
transmissions and a time based request number 190 of z 
corresponding to server 210 originated transmissions. The 
server 210 upon receiving the initialization TPDU 600 

15 transmits an acknowledgment TPDU 610 containing a request 

number 190 of y+1. Upon receiving the acknowledgment TPDU 
610 the client 200 transmits a data request TPDU 620 in 
which the pole bit 170 is set thereby requesting an 
acknowledgment. Since this TPDU 620 is a client 200 

20 originated TPDU the sequence number 180 is equal to the 
sequence number y of the previously transmitted TPDU 600 
plus 1 or y+1. The data request TPDU 620 also includes 
a request number 190 of z which is the sequence number 180 
which the server 210 will use to begin data transmission. 

25 Upon receiving the data request 62 0 the server 610 
transmits an acknowledgment TPDU 630 having a request 
number 190 of y+2 . The server 210 then begins to transmit 
the requested data with server 210 originated TPDU 
transmissions. These transmissions have sequence numbers 

30 180 beginning with z as requested by the client. A data 
TPDU 640 having a sequence number 180 of z and a request 
number 190 of y+2 is thus transmitted to the client 200 
with the pole bit 170 set to request acknowledgment. The 
data TPDU 640 also contains the client 200 requested data. 

35 Upon receiving the data TPDU 64 0 the client 200 transmits 
an acknowledgment TPDU 650 having a request number 19 0 of 
z+1 equal to the next server 210 originated packet 
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sequence number 180 expected by the client 200. The next 
client 200 originated transmission data TPDU 660 has a 
client originated sequence number 180 of y+2 and a request 
number 190 of z+1 . As can be seen by the illustration in 
5 Figure 6, the appropriate sequence number 180 and request 

number 190 depends upon whether the transmission and 
subsequent acknowledgment is a result of client 200 or 
server 210 originated data packet transmissions. 

A problem associated with server 210 originated data 

10 transmissions is that the server 210 has no way of 
recognizing whether an acknowledgment TPDU which it 
transmits to the client 200 was unsuccessfully received 
by the client 200. Likewise, a client 200 has no way of 
recognizing whether an acknowledgment sent by it to the 

15 server 210 in response to the server originated data 

transmissions has been unsuccessfully received by the 
server 210. To solve this problem the method of the 
present invention stipulates that an acknowledgment is 
implied if a packet is subsequently received which has the 

20 expected request number 190. 

Referring additionally now to Figure 7, there is 
illustrated a sequence diagram for requesting and 
transmitting data from a server 210 to a client 200 when 
acknowledgment messages are unsuccessfully transmitted. 

25 In response to the transmission of a data request TPDU 

700, similar to data request TPDU 620 of Figure 6, 
containing a sequence number 180 of y+1, a request number 
190 of z, and the pole bit 170 set, the server 210 
transmits an acknowledgment TPDU 710 having a request 

30 number 190 of y+2. The acknowledgment TPDU 710, for 
whatever reason, is not received by the client 200. 
Nevertheless, the server 210 transmits a data TPDU 720 
containing a sequence number 180 of z, a request number 
190 of y+2, and the pole bit 170 being set. Although the 

35 client 200 has not received the acknowledgment TPDU 710 
from the server 210, the client 200, following the 
methodology of the present invention, recognizes that the 
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request number y+2 of the data TPDU 72 0 contains the 
appropriate request number 190 and implies that an 
acknowledgment TPDU 710 has been sent by the server 210. 
The client 200, therefore, retains the data TPDU 720 and 
5 transmits an acknowledgment 73 0 having a request number 
190 equal to z+1 to the server 210. In a similar fashion, 
this acknowledgment TPDU 730 may be unsuccessfully 
received by the server 210. Nevertheless, the client 200 
transmits another TPDU, which for this example is data 

10 TPDU 74 0 having a sequence number 18 0 equal to y+2 and 
a request number 190 equal to z + 1. The server 210, 
following the methodology of the present invention, 
recognizes that the request number z+1 is the appropriate 
request number 190 and implies that the client 200 has 

15 transmitted the acknowledgment TPDU 73 0 even though it was 
not received by the server 210. The stipulation of 
implying an acknowledgment if a packet is subsequently 
received which has the expected request number 190 
prevents the client 200 and the server 210 from becoming 

20 out of synchronization with one another and constantly re- 
sending data packets to one another. 

Unlike Transport Control Protocol, the transport 
layer protocol of the present invention does not support 
a selective automatic repeat request methodology and thus, 

25 does not support the receipt of out of order packets. In 
the present invention, packets received out of order are 
discarded. If, however, a packet is received out of order 
but contains a request for acknowledgment, an 
acknowledgment is sent containing the request number equal 

30 to the sequence number of the last packet received in 
order plus one . 

Although a preferred embodiment of the method of the 
present invention has been illustrated in the accompanying 
Drawings and described in the foregoing Detailed 

35 Description, it is understood that the invention is not 
limited to the embodiment disclosed, but is capable of 
numerous rearrangements, modifications and substitutions 
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without departing from the spirit of the invention as set 
forth and defined by the following claims. 
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WHAT IS CLAIMED IS : 

1. A Transport Protocol Data Unit for a wireless 
packet data delivery comprising: 

a response bit for signifying the Transport 
5 Protocol Data Unit as a command or response Transport 

Protocol Data Unit; 

a poll bit for requesting an acknowledgment; 
a sequence number field for identifying the 
Transport Protocol Data Unit; and 
10 a request number field for communicating a 

sequence number of the Transport Protocol Data Unit 
requested to be next transmitted. 

2. A method for data packet delivery between a 
sender and a receiver, comprising the steps of: 

15 transmitting a user selected number of data 

packets, wherein each packet is sequentially numbered and 
each packet except for a last packet has a poll bit 
cleared, the last packet having the poll bit set; 

receiving the data packets transmitted by the 

20 sender; 

detecting the sequence number and the poll bit 
of each received packet; 

comparing the sequence number of each received 
packet against an expected sequence number; 
25 storing data contained within packets when the 

sequence number of the packet matches the expected 
sequence number; otherwise 

discarding the data packets. 
3 . A method for data packet delivery between a 
30 sender and a receiver, comprising the steps of: 

transmitting a user selected number of data 
packets, wherein each packet is sequentially numbered and 
each packet except for a last packet has a poll bit 
cleared, the last packet having the poll bit set; 
35 receiving the data packets transmitted by the 

sender; 
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detecting the sequence number and the poll bit 
of each received packet; 

comparing the sequence number of each received 
packet against an expected sequence number; 
5 storing data contained within packets when the 

sequence number of the packet matches the expected 
sequence number; 

discarding data packets when the sequence number 
of the packet does not match the expected sequence number; 
10 and 

transmitting an acknowledgment in response to 
the detection of a set poll bit, the acknowledgment 
including a request number equal to the expected sequence 
number . 

15 4. The method of Claim 3, further including the 

steps of: 

transmitting the data packet having the sequence 
number equal to the request number transmitted by the 
receiver in the acknowledgment; and 
20 transmitting all subsequent data packets. 

5. A method for data packet delivery between a 
client and a server when a client requested acknowledgment 
is not received by the client prior to the receipt of a 
subsequent data packet, comprising the steps of: 
25 receiving a data packet not containing an 

acknowledgment when an acknowledgment is expected; 

detecting a sequence number of the received data 

packet ; 

comparing the sequence number of the received 
30 packet against an expected sequence number; and 

implying that an acknowledgment was sent even 
though not received if the sequence number of the received 
packet matches the expected sequence number. 
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